EnigmA Amiga Run 1995 November/EnigmA AMIGA RUN 02 (1995)(G.R. Edizioni)(IT)[!][issue 1995-11][Skylink CD].iso/earcd/misc/noahsarc.lha/Noahs.Arc/Part5

Text File | 1995-10-05 | 29KB | 560 lines

  A few mentions on the new downloads:

The basic gang:

Conman - Only makes the CLI about 2000 times easier to use.  Use -q -t in
         your st-seq.  The F2 and F10 keys are great.

Less   - Allows you to Ed with "v".  Use "G" and "g" for top & bottom of page.
         Rename it as "Type" for your c directory, rename the original Type
         command to "Type2".  Yes...heh...you may want it some day.

PrefCh - When you go to set up a new screen color/pointer for some game or
         whatever, first "SetPrefs system-configuration", then work from
         there.  View the sys-con file in devs as your "master" Prefs.
         There are small BBS programs running around that'll let you save
         and load just the pointer.

Mackie - Must be RunBack'd in st-seq.  You can make it do different things
         but I like it straight up (pops up NewCLI with press of two keys).
         It's especially handy when you've got the DU and a bunch of windows
         open and you want a CLI window opened for just a sec.

Runback - Always/usually use instead of Run in a scriptfile (like st-seq).
          If yours came with all that null: stuff, disregard it.

Select - Can also be used at any time in a scriptfile by giving it different
         options.  There are lots of these st-seq `choosers' around

DL - The search for the Perfect List Command is an endless one.  This is a
     decent one, as is JBLS

  Update Note:  When you type "List ?" to see the template of the hot, new
1.3 List command, the damn thing's almost got two lines of options..but is
there an "all"?  No-o-o-o...  Is there a "pat" or "sub" option that we might
possibly use?  No-o-o-o...  Don't these people understand that we might
become so desperate that we'll end up using one of our treasured wildcards to
list ALL the files?  No-o-o-o...  Will this be the major embarrassment of my
life if it's some simple combination that I just haven't tried yet?

  Well...no.  But close. :)


("Gee, Boss, what's a wildcard?", you ask.   Heh heh heh...)


DU-VI - See that gap in between the two screens?  I kept thinking, boy, what
        a blow-it, you think he would have noticed!  Then, while fumbling
        about one day moving the right window out of the way so I could get
        to the Ram icon, I realized, oops, wasn't a blow-it at all!  I was
        just kind of keeping my icons over on the right 'cause that's where
        they'd always been, but obviously you can Snapshot them wherever
        you want..so now I have my Ram and Workbench icons under that gap
        so I can get to them when the DU's up.

        If there's any "bug" with DU-VI it's that it has its own Type
        program built-in, and you can't use Type (Less, renamed as Type)
        which is really a drag, Less being so much better.  Put "Run Ed" in
        the Edit requester instead of just "Ed", so you can still use the
        DU while the Ed window is up.  To "refresh" a directory, click in the
        lower box behind the directory's name, and then Return.  In general,
        get into good DU habits, such as always copying from, say, the left
        screen to the right, or always putting df1 on the right side, Ram on
        the left, that kind of thing.  Doing some real file-shuffling?  Pop
        up TWO!

Zoomlens - For just a simple tool this can get pretty surreal.  It's a
           standard IconBench tool.

PlayBeep - I love this guy.  Gets rid of that nasty screen flash and substi-
           tutes whatever little IFF sound file you wish.  There's a great
           "ow.snd" off a similar program called SetBeep you gotta try, but
           don't use SetBeep..it screws up the audio.device for other pro-
           grams, especially AmigaBasic ones.  PlayBeep seems okay.

                                       *

  Might as well take a minute and skip through friendly ol' IconEd.

  The manual covers IconEd surprisingly in depth.  (they practically skip the
startup-sequence, but do an elaborate job on the icon editor...go figger) The
only thing that took me a bit to catch on to was: Let's say you have a neat
icon, but it's a Tool icon for some utility/program/tool (the words all kind
of blend together after a while...) and you need the icon to be a Project
icon.  To see what type of icon it is, you activate it and pull down the Info
menu, right?  If you have FileType (renamed as "WhatIs"), you can use that.

  So you pop up IconEd and Load up a Project icon, any one will do.  Now move
to the next editing window and Load your neat Tool icon.  Go back to the
first window, erase the sucker (Undo Frame), bring the good icon over (From
Frame), Save that guy and that's it.  It's a Project icon because you saved
through the window you loaded up that original Project icon in.  Whew.

                                       *

If you're having problems finding, loading, saving things, it's probably
because of "pathnames".  The bottom line with pathnames is, when in doubt,
use longhand.  That is, write out the whole path, including the device name.
If you're not sure where you are, and want to save something to the Utilities
dir, just type out "df0:Utilities/<filename>".  You'll eventually type "df0"
so much that you'll type it before you know it.

                                       *

  Let's go over CD for a sec just to make sure you're familiar with it.  If
there's any command on the disk that's "yours", CD is it.  Basically, it
means you, meaning your fingers, meaning the keyboard, meaning where the
commands being typed on the screen are coming from.  You can CD onto any
device and into any directory.  Type "CD Ram:" and you're in Ram.  How do
you know?  Type "CD" and it'll tell ya.  If you type "Dir" then you'll be
shown what's in "your" directory and/or device.  Type "CD df0:System",
then type "Dir".  Dir will show you what's in the directory you've CD'd to,
the System directory.  You don't have to CD to a directory to find out what's
in it, of course.  Type "CD df0:", then type "CD" and it should spit the
Bench's name back at you.  Type "Dir" and there's the stuff on the "surface"
of the disk.  Then type "Dir System" and there's the System stuff.  You
already know this?  Great, no problem.

  CD can save us a bunch of keystrokes if we're writing a scriptfile and
have to copy or rename or whatever a bunch of files buried deep in some
directory.  Let's say we've got a disk with nothing but IFF pictures on
it, a whole bunch of them, all in separate directories.  We want to copy a
small handful of them to Ram to use with some graphics thing.  The pics we
want are in a directory on df1 called Modern, inside a directory called Art,
inside a directory called Pics, inside a directory called Graphics.  Since
this is confusing enough, we'll just call the pics 1,2,3,4 and 5.  So we
could type:

                     Copy df1:Graphics/Pics/Art/Modern/1 Ram:
                     Copy df1:Graphics/Pics/Art/Modern/2 Ram:
                     Copy df1:Graphics/Pics/Art/Modern/3 Ram:
                     Copy df1:Graphics/Pics/Art/Modern/4 Ram:
                     Copy df1:Graphics/Pics/Art/Modern/5 Ram:

  Whew!  With the CD command, we can do this:

                     CD df1:Graphics/Pics/Art/Modern
                     Copy 1 Ram:
                     Copy 2 Ram:
                     Copy 3 Ram:
                     Copy 4 Ram:
                     Copy 5 Ram:

  See that?  It put us into the Modern dir and then when we said to Copy
(or Rename or whatever) the files, the computer knew just where to find them,
as it was right there "alongside" us.  The computer can only "be" in one
spot at a time (not speaking about multitasking) and CD tells it where
you're going and you where you are.

  CD is tied very closely to pathnames.  If you type CD in a CLI window
and it spits "Workbench:" back at you, you're sitting there on the surface
of df0.  If you want to dir the devs directory, you don't have to type out
the whole pathname, "df0:devs", just "Dir devs", as the computer, who's
there alongside you, knows to look around for a "devs" directory, and it
finds it.  Now "CD devs", which puts you into the devs directory, then
"Dir devs".  The computer looks around for a "devs" dir and doesn't see one,
as there's no "devs" dir in devs.

  The same would hold true if you CD'd to Ram.  Type "CD Ram:", then "Dir
devs", and hey, devs not found.  Issue the whole pathname, "Dir df0:devs",
and there it is.  The point being, again, that the CD command is YOU; what
window you're typing from, from what device and what directory, and from
where the computer is going to look when you or a scriptfile issues it a
command.  This is the gist, baby.

                                       *

  Ah yes, wildcards.  Now, I don't know if the guys down at the store told
you about this or not, 'cause it's kind of secret deal, but each Amiga comes
stock with three wildcards, which will override any copy protection, disk
error or system security you hand it.  The catch is, of course, that you
only get to use them once, then they're gone.  I used one just a few weeks
ago, when Beyond Dark Castle wouldn't diskcopy successfully.  I probably
blew it (I DO have a warranty card), but I really wanted a copy right away,
so I used my own computer's secret key combination and bang, there it was.
Okay, so it was an expensive copy..having a backup means a lot to me.  Which
leads us to the cost of new wildcards.  You can bet they're expensive, and
you can bet they're hard to get.  Plead as you might, you'll be hard-pressed
to get the salesperson to admit they've got any.  I find them handiest when I
want to make a free long-distance phone call, or change my bank account
balance.

                                       *

  As far as the words "directory" and "drawer", ou might as well get used to
them meaning (approximately) the same thing, kind of like that program/tool/
utility business.  I'm tending to just use them as the occasion fits; you
put things into drawers but you Dir a directory, yes?  What you have to
realize, and yes it comes as a surprise, is that there are "purists" out
there who completely disdain the entire Workbench environment, windows, icons
and all.  Perhaps "elitists" is the word.  Irregardless, it's just another
word for "old-fashioned".  You'll find after a few months the keyboard and
mouse blending together quite nicely.  There are certain functions that
naturally fall into the CLI's domain, and certain ones that just cry out for
a cute icon.  And right in the middle of it all is the big ol' DU.

  And as long as we're talking about putting the knock on friendly ol'
Workbench, you'll also hear our DOS being put down here and there but, not
to fret.  Just take a glance at an MS/DOS book (IBM language) sometime and
you'll quickly see there's no comparison.  We're talking about two completely
different things.  Ours is just perfect for what we want to do, proven by
asking the question "Just what commands are we MISSING, anyways?"  The only
command "missing" is a "Move" command, as Rename won't move something to a
different device.  But that's about it.  Naturally, there IS a Move command
on the BBSs.

  And another thing:  You'll hear mention of "bugs" in AmigaDOS.  The "arp.
library" are the "fixed" versions.  I've never had a command NOT work, given
everything else was in place, so frankly I don't have the foggiest idea what
they're talking about.  Unless you know better, I would call substituting
our commands with the arp.library "looking for trouble".  There are a few
arp commands that are better than the stock commands, though.  The Rename
and Copy commands are a little more flexible.

  Update Note:  I'm now using OS 3.1, but STILL using the very-smart arp Copy
and Rename commands.  It's their use of wildcards that's (still) so much
better than Commodore's.  Oops!  Did I say "wildcards"?  Sh-h-h!

  I kinda feel the same way about the (real) Shell program you'll hear some
people raving about.  It's huge, byte-wise, claims to replace your c
commands but doesn't really, and by the time you add this complicated
program to "simplify" things, you're less than breaking even.  If you just
want your commands to be speedy-quick, well, we'll get to that.

                                       *

  One of the nicer things about the Workbench environment is being able to
take an icon and "store" it on the Workbench screen, enabling us to close
that window and make some space, yet still having the program a click away.

                                       *

  Okay, now some stuff on (real) wildcards.  Sorry about the above.

  Just couldn't resist. ;>

  If you want to delete all the stuff on a disk in df1, and enter "Delete
df1:  all", it'll tell you "df1: is a device and cannot be deleted", and
justifiably so.  To tell the computer that, yes, you know what you're doing,
you use the same ancient combination of mystical symbols the Arabics used as
they scribbled on their tablets of clay:

                                     #?

  As in "Delete Ram:#?", or "Delete df1:#? all".

  The "all" option works the same way with devices as it does with direct-
ories.  "Delete Ram:#?" deletes all the files on the surface of Ram,
"Delete Ram:#? all" deletes the whole ball of wax.  I didn't want to confuse
you earlier when we cleaned out the s and fonts dirs by deleting (all), but
the correct command should have been "Delete s/#?", to clean out the s dir
without also deleting the actual directory.  Ditto "Delete fonts/#? all".
The "delete fonts" gets an "all" because of the font sub-dirs.

  Another common use of the #? wildcard is when you want to Dir or List a
large directory (or device) and only list certain related files.  If you
wanted to see which icons were in the Utilities directory, you'd:

                         Dir Utilities/#?.info

  See that?  It looks in the Utilities directory for any file that ends with
".info".  It works the other way around, too, like if you wanted to list any
files in the c directory that started with the letters "del", you'd:

                         List c/del#?

  There are a few different combinations of wildcards that you'll want to
become familiar with, and they're well-documented in the DOS books.  Another
common example would be using them with the Copy command.  Want to copy all
the icons in the Utilities directory to Ram?  "Copy Utilities/#?.info Ram:",
that's it.  The "#?" is terrific.

                                       *

  "Sys:" is kind of a "floating device name", as it were.  In the Tool Types
box of some text icons , it'll say "Sys:c/Type".  So when you double-
click on them in df1, the computer, knowing by default that whatever drive
holds the boot disk is "sys:", looks in df0's c dir for the Type program.
If you have a hard drive, somewhere in the st-seq you'd "Assign sys: dh0:",
and now when you click on the icon it reads the Type program out of the hard
drive's c directory.  This way, one icon (for a scriptfile or tool) can
operate from more than one device, which is the reason the stock 1.3 Bench
is laced with "sys:".

                                       *

  If you haven't downloaded Conman yet, you're really missing the boat.  I
guarantee it'll be one of your best buddies ever.  I give it my highest
praise: It should have been included with the original software.  I'd even
settle for that Tools dir on the Extras/Basic disk.  Which, yes, we'll get to
eventually.  Don't hold your breath, though, there's not much on it for us
of the computerati illiterae.

                                       *

  Figured out that deal with Notepad and the fonts yet?  Test time is near!

                                       *

  There are two great keyboard commands that as far as I know aren't
documented anywhere, probably a 1.2 upgrade.  I read about them in a
letter to AmigaWorld..what can I say?  They're left-Amiga-N and left-Amiga-M.
They flip you back and forth between screens, two valuable commands.  If a
program, like GShow, mentions "toggle", that's possibly what it means.  To
be fair, I think I did see them buried in one of the books eventually, but
in some obscure context.  They should have been highlighted in Chapter Four.

                                       *

  You're probably getting a handle on Path, that elusive rascal.  Path shows
the computer where directories are so it can find tools when you command it
to.  One thing you have to remember about Path is that it only leads to the
dir you name, even if it has to go through a couple of directories to do it.
The directories it goes through to get to yours are not in the path unless
specifically named.  Just Path every directory that has a tool in it you
might want to access through the CLI or a scriptfile and be done with it.

  A sidenote about Path:  The more directories and devices you have in
the paths, the longer it takes your computer to spit back an "unknown
command" at you, as it's looking through more dirs and devs.  This gives the
impression that the computer is "operating slower", but it's not, of course.

                                       *

  Okay...NOW we'll do Assign.  Nothing to it, really.  Simply Assign
anything to what you want and that's it!

                                       *

  Now I'd like to say a few words about the program IconX.  It's one of the
more integral tools on the Workbench, meaning that it touches a lot of
areas of the computer.  I'm not going to call it a sub-routine, though,
as it only works when called upon, like any tool, whereas Mackie and
FaccII and the like are always running in the background, and that's
easily proven by quitting the programs and watching the memory they were
using come back.  Some sub-routines, like Conman, don't have OFF switches,
so once they're run, the memory's gone forever.  That, again, is where
Select comes into play, which makes it so impor-  What's that?  You
thought the section on Assign was kind of skimpy?  Are you sure??  Look,
I'll make you a deal:  YOU solve the Notepad/fonts puzzle and I'll give you
another whole paragraph on Assign..fair enough?  Now put this down and get
busy, gol'dang it!

                                       *

  Generally, the standard procedure for using IconX is this:

  Let's say we want to run a program, any program, say, Notepad for instance.
The only hitch is that on the Bench we've only got some lonesome ol' TBM or
topaz kickin' around the fonts drawer, all the good stuff's on Fontdisk in
df1.  We haul out faithful Ed and write up a scriptfile for IconX to run.  We
type "Ed Utilities/Notepad!", note that the exclamation mark differs it from
the program "Notepad".  You can use any name, "Note.Pad" for all I care,
just so long as it's not the actual program's name.  So our scriptfile
looks like this:

                          Assign fonts: df1:fonts
                          df0:Utilities/Notepad
                          Assign fonts: df0:fonts


  First we assigned the fonts directory over to the one on df1, so when
Notepad went looking for "fonts", it was re-directed to the fonts dir on df1.
Then we ran the Notepad program, but we didn't Run it, that's the trick.  If
we'd Run it, the scriptfile would have continued, the fonts dir would have
been reassigned to df0 and Notepad wouldn't have found them.  This way they
stay on df1 until the Notepad program is ended, allowing the scriptfile to
continue.  This is an elemental part of the whole Amiga scheme so make sure
you understand it.  Did I call it a "puzzle"?  Excuse me.

  So you've got your file written, Esc, x, Return to save it.  The next step
is to change the Notepad icon from a Tool to a Project type, as IconX needs a
Project icon to run from.  If you don't have IconType or IconLab yet (where
have you BEEN?), haul out good ol' IconEd, load up a Project icon and the
Notepad tool icon and do the switch.  Save it as "df0:Utilities/Notepad!"
(the .info is added automatically) to match our (!) scriptfile.

  Close IconEd, open the Utilities drawer and there our icon should be.
Double-click it just to watch the error message and make a fool of yourself,
then activate the icon and pull down the Info menu.  Activate the Default
Tool box with the mouse and type in "df0:c/IconX", hit Return, then SAVE
the Info.  Ready for the big moment?  Double-click the icon, things should
scratch around for a while then up Notepad should pop.  Check the fonts to
make sure they're loaded.  Quit the program, the fonts should re-assign
themselves to df0, and that's that.  You find out what things are currently
assigned to by typing "Assign".  The box IconX popped up is VERY valuable
when getting a scriptfile running as that's your feedback window, which,
hopefully, will tell you if something's screwing up.  Like if you didn't
have FontDisk in df1 and the Assign failed, it'll tell you.

  An improvement in the scriptfile would be to say

                         Assign fonts: FontDisk:fonts

to make sure the Assign seeks out the disk by name, in which case you'll get
a requester if Fontdisk isn't in one of the drives.

  IconX is a 1.3 addition; up 'til now everyone's been using a BBS program
called Xicon.  Xicon is much more versatile than IconX, but for just running
scriptfiles, IconX works fine.  The only thing I don't like about IconX,
and why I'm going to keep on using Xicon, is that evidently you can't keep
the window from opening, which I think is really tacky.  And I have to
assume the window's wasting some thousand bytes or so of graphics memory,
which borders on the unethical.  If you're already used to it, you might as
well keep using it.

  Update Note:  I think I finally saw a way to keep it closed, something like
"WINDOW=NULL", but it might have been 2.x or 3.x-only.

  IconX, remember, is only for running scriptfiles from the Workbench.  You
could always copy that Notepad! script to "n", put it in the s dir, and as
fast as your fingers could type "f n", you'd be on your way.  Given how
small, byte-wise, a scriptfile is, you could have both.  But, but I hear
you ask, as long as you have to fiddle around with icons to get a CLI open,
why not just punch the Notepad! icon as long as you're there?  Well that, my
friend, is because you don't have a handy little CLI window or two pop open
down at the bottom of your Bench during boot-up for just such an occasion.

  But you will, you will...

                                       *

  The thing to understand about Assign is that it's not complicated, al-
though it seems kind of hairy because we're dealing with device names and
some of our major directories and such.  What it really is, is kind of a
Temporary ChangeName command:

                     ChangeName (oldname) to (newname)

  Then if a program looks for the device "oldname", it finds "newname",
instead.  Very easy.

  If we mention the "fonts" to the computer, like "Dir fonts", it's thinking
"df0:fonts".  So in Notepad's case we:

                     ChangeNamed "df0:fonts" to "df1:fonts"

                              or

                     Assign fonts: df1:fonts

  Now when Notepad goes looking for "fonts", it'll find "df1:fonts", instead.

  There might be the odd occasion where we'd want to have the libs dir in
Ram for speed and/or lack of disk access.  Something like:

               Makedir Ram:libs        ;makes a libs dir in Ram
               Copy libs Ram:libs all  ;copies the stuff in libs to Ram
               Assign libs: Ram:libs   ;Assigns "libs" to "Ram:libs"

  Now when some program goes seeking a lib, the dir "libs" has had its name
changed to "Ram:libs" and the program seeks it there.

  With my hard drive I boot up with a regular Workbench, but at some point in
the st-seq I assign most of the Workbench dirs over to the dirs on the hard
drive.  If I "Dir devs" the computer is thinking "Df0:devs", so in the
st-seq I "Assign devs: dh0:devs".  So now if I "Dir devs", the computer
thinks "dh0:devs". I ChangeNamed (assumed df0):devs to dh0:devs.

  If you're booting up from your hard drive, then "sys" is "dh0:", so a "Dir
devs" will read "dh0:devs" by default, and you won't need to Assign the Work-
bench directories over to the HD.

  Occasionally some new program you're trying will suddenly pop up a
requester saying something like "Please Insert Disk So-And-So:", so at some
point in your scriptfile you'd "Assign So-And-So:  df0:Games" or whatever dir
you've got the program in.  Some programs have their own special fonts they
want to use, so you'd put the fonts in their own little dir in the programs's
dir, then "Assign fonts:  df0:Games/fonts".  So when the program goes looking
for "fonts", it's re-directed to "df0:Games/fonts".  Then you finish up the
scriptfile with an "Assign fonts: df0:fonts" to return things to normal when
through.

  That may not have sounded like much, but that's an excellent example of why
scriptfiles are so important.  In this example, you don't have to clutter up
your fonts directory with tens of thousands of fonts over the next number of
years.  Ditto libraries...and libraries are MUCH bigger than fonts.

  Try "Assign X: df0:Clock".  Type "X:" and you get the Clock. Hey, saved
you a whole three key strokes!  Well two, since you had to use the shift key
for the colon.  I don't recommend this usage of Assign, but I felt obligated
to show it to you. :)

  A common usage for Assign would be if you've got some horrendously long
path name you have to work with.  You're copying a bunch of pics in the
directory Pics/ToGo to a disk in df1 named "Pictures:", to the directory
BunchaNewPics/MyFaves/Latest/Recent/New.  Whew! <wiping brow>  You'd:

           Assign XX: Pictures:BunchaNewPics/MyFaves/Latest/Recent/New
           CD Pics/ToGo
           Copy Julie.pic XX:
           Copy Space.pic XX:
           Copy Waterfall.pic XX:
           <etc>

  Goof around with Assign for a while until you feel comfortable with it..you
can't hurt anything and you can always reboot if you completely lose it.

                                       *

  A few words on If, EndIf and Else.  Unless you want to be clever and start
using all the sub-commands that go along with these three, things are fairly
straightforward.  Take a glance in one of the DOS books if you forget the
correct layout.  Basically, it just checks to see if a file or directory is
there, or not there, and then does something, or not.  The something it
does can be a whole string of commands, or just one.  Ditto if the file
isn't there.  They can completely make or break a scriptfile, so note how
they're used, and remember it. :)  The If command is really neat.

  1.2, 1.3-only:  IconX doesn't execute a scriptfile like Execute does, it
just runs the commands line-by-line.  Because of that, the computer doesn't
recognize it as a "scriptfile", so the If/Else/EndIf commands won't work.  If
you're running a scriptfile with IconX that has an If/EndIf parameter in it,
you'll have to rename it to something else, let's say "Game.scp", and have
the IconX file do nothing but execute it, like "Execute Game.scp".  That'll
execute things properly, allowing the If/EndIf's to work.

                                       *

  And goofy old IconX is, yes, the answer for the CLI-Stack problem:

  - Assuming your CLI program is on the surface of the Bench, issue the
command "Copy CLI.info BigStack.info".  That duplicates the CLI icon and
renames it BigStack.info.

  - Use whatever method you prefer to change the BigStack icon from a Tool
type to a Project type.

  - In a CLI type "Ed BigStack", and in the new Ed file, enter the two lines:

                     Stack 16000
                     Run df0:CLI

  Hit Esc, x, Return to Save.

  - Open up the BigStack icon and enter "df0:c/IconX" in the Default Tool
box, then Save.

  - Give it a try!

                                       *

  A fresh challenge:  Here's a problem that might make you do a little
creative thinking.  I mentioned it before but you probably haven't tried
it yet.  It was the placing the Ram icon behind the gap between the DU's
windows.  Or placing the Ram icon wherever you want, for that matter.  You
can't just Snapshot it there like you can the Workbench one, because it just
saves the information in Ram, which goes bye-bye when you reboot.  Your
homework is this:

  Upon booting up, you should have a custom, NOT default, Ram icon in the
specific location of your choice.  Its window has to open up just where you
want.  Extra credit will be given if you Dir Ram after booting up and there's
no icon listed.

  You have until near the end of the tutorial to solve this mighty poser.

                                       *